1. Field of the Invention
The present invention generally relates to the execution of programs (software codes) by an integrated microprocessor. The present invention more specifically relates to the control of the integrity of a program during its execution, to check that it is executed with a normal sequencing, that the program has not been voluntarily or incidentally modified since its installation, be it prior to its execution or during said execution. Such modifications may result from computer viruses or piracy attempts including, more specifically, injecting faults in the program execution.
2. Discussion of the Related Art
A so-called trap fault injection attack may include the introduction of a disturbance on the processor power supply for a short time. Such an attack may cause an unexpected jump in the program execution sequence. An example of application is the case of a processor that must decide whether a specific operation is allowed (for example, in the case of credit cards, the authorization of a bank transaction after authentication of the user).
Such types of attacks affecting, for example, the execution of a cryptography algorithm may include having the program counter jump to cause an unexpected jump in the execution sequence by any means, even if the program has not stopped or is in a loop upon authentication. For example, for cryptography algorithms (DSA, RSA, DES, AES, etc.), the secret keys can be discovered by a piracy causing instruction jumps.
According to another aspect, the pirate attempts to modify the program sequencing on execution thereof. In the case of a smart card, this sometimes amounts to modifying the order of commands received by the card processor, sometimes inserting abnormal commands in sessions of communication with the card. The pirate's aim then not necessarily is to discover a secret, but to divert the application executed by the card, for example, to fraudulently extend a utilization period managed by the card (a transportation ticket, for example).
According to the application, the program to be protected is contained in a ROM written into upon manufacturing and not modifiable or in a rewritable non-volatile memory, for example, a flash memory.
To protect the software code upon execution thereof, a periodic checking of this code is generally provided based on an authentication key stored in a memory or in the integrated circuit, for example, upon initial storage of the program or installation thereof. For example, a signature (application of an encryption algorithm to at least a portion of the software code) is calculated upon installation or writing of the program. This signature is then stored in or outside of the integrated circuit executing the program. Then, upon execution of the software code, the operating system recalculates a signature based on the same algorithm as that used for the generation of the initial signature. The current signature is then compared with the predetermined signature. A divergence between the two signatures means that the stored program has been modified and thus enables identifying a potential unwanted or incidental attack. An example of such an integrity check method is described in U.S. Pat. No. 5,442,645, which is incorporated herein by reference.
A disadvantage of known solutions with signatures is that, in case of an updating of the software code by a more recent version (case where the program is in a rewritable memory), it is then necessary to update the predetermined signature. Such an updating may be penalizing especially in case of a frequent updating of the system. Further, the updatings of programs occur more and more often via communication networks of Internet type. It is then not desirable to multiply signature calculations to be rerecorded in the integrated circuit on the user side.
Another disadvantage of conventional solutions with signatures is that the integrity check is static, that is, at the beginning of the program, it is checked whether the signature is actually allowed. Accordingly, such a protection system is in practice inefficient in case of a fault injection during execution of the program.
Another known solution to control the execution of a program is to perform certain operations twice, to have a redundancy on the data to check the coherence between the two executions.
A common disadvantage of the above-discussed known techniques is that they are greedy in calculation resources. Accordingly, they are poorly adapted to low-power integrated microcontrollers, as for example those available in smart cards.
An additional technical problem which is posed in the control of the execution of a program is that a same section of the program (for example, a writing of a number into the non-volatile memory) may be more or less critical according to the sections which have been previously executed by this program. In other words, the same operation performed by a microcontroller must or not be considered as a piracy attempt according to the place where it is located in the program execution. For example, the checking (request of entry by the card reader) of a secret code several times consecutively in a smart card, without for this checking to come along with an operation (debit, balance checking, etc.) between the checkings, is suspectable. The same code checking is however normal if it is followed by a processing operation conditioned by this checking.
This problem is not solved by known program execution control techniques.